Session Initiation Protocol (SIP) is a signalling protocol used for managing calls and other multimedia sessions over an IP network. SIP can be used for initiating, controlling and terminating such sessions. These interactions are carried out using requests and responses passed between the calling and called parties.
SIP messages are normally transferred using User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) as the transport protocol. Each of these has its own advantages and drawbacks. TCP, which is a connection-oriented protocol, has the advantage of guaranteeing transmission of messages. However, this can be problematic when the connection between endpoints fails. UDP, which is connectionless, can suffer from packet loss. However, UDP allows signalling to continue after a failover to a backup device.
As a result, both of these protocols provide greater advantage in different situations and conditions. Consequently, neither has an overriding advantage and there is divided opinion on which protocol should be preferred overall. It is estimated that the proportion of applications using TCP is roughly similar to those using UDP, with perhaps a slight preference towards UDP.
FIG. 1a shows a simple network configuration to demonstrate the issues. This network includes two phones 12,14, each connected to two different servers 10,11 from behind a NAT (network address translation) device 13,15. Server A is the primary server and Server B is a backup server.
In this example, each phone would normally register with the primary server (Server A) over TCP, thus setting up a TCP pinhole through the network address translation (NAT) device 13. When a phone wishes to initiate a call, it will send a standard SIP INVITE message, which will also use this TCP pinhole. TCP might be used for several reasons. TCP supports fragmentation so does not impose a limit on the size of a message and call set-up can often involve large messages to include all the media information. TCP is more secure, particularly where NATs are concerned, because it allows better identity and address authentication. TCP also guarantees transmission and servers, particularly in large networks, do not want the overhead of dealing with retransmissions.
Once the call has been initiated over TCP, the media path flows directly from Phone A to Phone B and so is not vulnerable to any problems with the servers. The signalling path for in-call updates and session refreshes, however, still flows along the same TCP connection (Phone A→Server A→Phone B), so any in-call SIP messages need to use this path.
In the example of FIG. 1b, Server A becomes unavailable during the call, for example because it crashes or because of a network failure. This will cause the TCP connections to Phones A and B to be torn down and, most likely, the call to be terminated. Even if the call is not terminated immediately, no further signalling will succeed so any in-call updates or session refreshes that would normally keep the call active will fail.
This means that if both parties want to continue talking, Phones A and B need to attempt to re-establish the call through Server B. This will certainly cause the call to be dropped and the end user to have to perform manual steps to re-establish communication with a new call.
If the call had been initiated using UDP, rather than TCP, the failure of Server A would not cause the call to be terminated. This is because UDP is a ‘connectionless’ transport and so the failure of one server does not prevent another from sending messages related to the same call or session. In the example of FIG. 1b, this means that Server B could take over communication with the two endpoints. This would allow the call to continue using Server B for any in-call updates or session refreshes.
As shown in FIG. 1a, the phones (or clients) are behind a NAT device which restricts access to the phone from outside, including from the server. The server can only contact the phone if a NAT pinhole has been opened, usually by the phone sending a message out through the NAT. Thus if the phone has contacted the server using TCP then a TCP pinhole may be open allowing communications from the server to the phone using TCP. Similarly, if the phone has contacted the server using UDP then a UDP pinhole will be opened allowing communications from the server to the phone using UDP. However, if TCP is used to establish a SIP call and a server fails, it is not possible to switch to using UDP without opening a pinhole in the NAT first. As the pinhole can only be opened by the phone/client, the server would have to wait for communication to be re-established before it could send any messages.
The present invention aims to avoid or ameliorate some of the problems with the system described above.
The problem this invention aims to address is how to obtain the benefits of using TCP in registrations and call set-up, but also make use of the benefits of UDP in being able to preserve signalling following a failure of a connection or server. This is particularly relevant to clients or phones behind NAT devices or firewalls.